1. Field of the Invention
The present invention relates to a member-exclusive service system and method through a communications network such as the Internet, etc.
2. Description of the Related Art
With an increasing use of personal computers, users can receive various services through communications lines. "REMOTE INSTALLATION AND METHOD of U.S. patent application Ser. No. 08/585,017, and Japanese Patent Laid-open H8-190472" is an example of the conventional technology of automatically distributing software through communications lines.
The conventional remote installation service system (RIS system) is composed of a host computer installed in a software distribution center, a user terminal, and a communications line connecting the host computer and the user terminal. The host computer stores a group of software including a plurality of pieces of software to be distributed, a first key table, and a second key table for storing a keyword list used in selecting a particular piece of software from the group of software.
If a user requests the host computer for the keyword list from the terminal, the host computer sequentially transmits the first and second key tables, and instructs the display unit of the terminal to display the keywords included in the keyword tables on the screen. The user selects any of the displayed keywords corresponding to a desired piece of software, and notifies the host computer of the selected keyword.
The host computer instructs the display unit to display a menu including several names of software corresponding to the notified keyword. The user selects a desired piece of software from the menu, and notifies the host computer of the selected piece of software. Then, the host computer retrieves contents of the piece of software selected by the user from the group of software, transmits it through the communications line, and stores it in a distribution directory installed onto a hard disk of the terminal.
At this time, an icon for invoking the software distributed to a user is automatically registered, and displayed on a directory window arranged corresponding to the directory on the screen of the display unit. If WINDOWS is installed on the terminal, the distributed software is registered in the program manager of WINDOWS. Then, the user can use the distributed software by simply selecting an icon with an input device such as a mouse, etc.
Provided next is the explanation about a flow of operations of distributing software to a user performed by the conventional remote installation system, by referring to FIGS. 1A through 1C.
In FIG. 1A, a terminal of user A obtains information about an operating environment when terminal software for a communication is installed, and creates an environment file 1 where the obtained information is stored (step S1). At this time, the terminal of the user A obtains information which requires a long time to obtain, such as a machine type of the terminal of user A, a storage location (directory) SOUKO, etc. used for a distribution, etc., or information which requires an inquiry to the user as necessary.
To set "SOUKO" indicating a storage location, the terminal examines whether or not a hard disk includes an empty area equal to or larger than a predetermined capacity. If the empty area exists, a directory for a door-to-door distribution is created at the root. At this time, the terminal automatically generates a directory name, etc., and the user A performs a verifying operation only. Accordingly, user A is not required to enter the directory name, etc.
In this case, for example, it is written to the environment file 1 that the machine type of user A is "TOWNS" and the directory of SOUKO is "D:SOUKO" (the directory SOUKO in a drive D). User A may change "D:SOUKO" to another directory if necessary.
If there is no empty area of a predetermined size in a partition of the drive specified in advance, the largest empty area is searched for in other partitioned areas, in order to create the directory for a door-to-door distribution. By way of example, if the directory D:SOUKO becomes full, the terminal 23 displays a message such as "D:SOUKO is full. SOUKO is changed to F:SOUKO. Is this OK?" on the screen of a display unit 24.
When the user A answers YES, F:SOUKO becomes a new directory SOUKO for the door-to-door distribution. If no hard disk includes an empty area of the predetermined size, a message such as "Disk capacity is insufficient. Add extra disk capacity" is displayed.
When the terminal software is invoked (when access is made to the host computer), information which may have varied after the installation, such as the state of the hard disk or memory, etc. is obtained (step S2). In this case, the hard disk of user A is designated as drive D, and it is written to the environment file 1 that its available capacity is 300M bytes. The contents of the environment file 1 created according to the above described procedure are transmitted to the host computer by a command RIS.sub.-- SENDENV when user A accesses (connects to) the host computer (step S3).
The host computer stores the received information as a user A environment file 2. The user A environment file 2 includes information such as an OS (operating system) currently being used and its storage location in addition to a machine type, hard disk information HD, and a storage location SOUKO. It is known from this file that the OS running on the terminal of user A is WINDOWS, and D:WINDOWS is WINDIR indicating its storage location.
When receiving RIS.sub.-- SENDENV*RESP OK as a response to the command RIS.sub.-- SENDENV from the host computer, the terminal requests a first key list with a command RIS.sub.-- KEYLIST (step S4). In response to this request, the host computer sends back the contents of a first key table 3 with a command RIS.sub.-- KEYLIST*RESP. In this case, the first key table 3 includes keywords such as an OS/basic software, a development support, a game, etc. corresponding to key numbers starting from 1.
When the keywords are displayed on the screen of the display unit (step S5), user A selects a first keyword from among them, and enters it to the terminal (step S6). Then, the terminal transmits a command RIS.sub.-- KEYLIST requesting a second key list together with the key number of the first keyword that user A selects, to the host computer (step S7). Since user A selects the game as the first keyword in this case, a key number 3 corresponding to the game is transmitted to the host computer.
The host computer to which a request for the second key list is made obtains a corresponding second key table 4 using a pointer stored in the first key table 3 according to the received key number, and returns the contents of the second key table 4 with the command RIS.sub.-- KEYLIST*RESP. The second key table 4 includes keywords such as an RPG, an action, a puzzle/quiz, etc. corresponding to key numbers starting from 51.
The second key table 4 includes a plurality of keywords corresponding to the keywords included in the first key table 3. The number of the keywords in the second key table 4 is equal to or less than the number of the keywords in the first table 3. If the number of the keywords in the second table 4 is less than the number of the keywords in the first key table 3, two or more keywords in the first keyword table 3 point to one keyword in the second table.
When the keywords in the second key table are displayed as the second key list on the screen of the display unit (step S8), user A selects the second keyword from the displayed keywords, and enters the selected keyword to the terminal (FIG. 1B, step S9). Then, the terminal transmits a command RIS.sub.-- LIST for requesting a list of software corresponding to the first and second keywords together with the key numbers of the first and the second keywords selected by user A (step S10). Since user A selects action as the second keyword in this case, a key number 52 corresponding to action is transmitted to the host computer.
The host computer to which the list of software is requested, searches for software having the two key numbers of the first and second keywords within a group of software. At this time, the search is performed without making a distinction between the first and the second keywords as a search condition. Additionally, the search is performed in consideration of a machine type and an OS type labelled as default keys. This prevents a search for software supported by machine types other than the TOWNS.
Then, a list of the names and numbers of the corresponding software are transmitted to the terminal together with a command RIS.sub.-- LIST*RESP. Since Tetris and a pinball game respectively having the key numbers 3 and 52 correspond to the software in this case, the names of Tetris and the pinball game are transmitted to the terminal together with the software numbers 5, 30, etc.
When the list of software is displayed on the screen of the display unit (step S11), user A selects desired software from the displayed list, and enters it to the terminal (step S12). The terminal then transmits a command RIS.sub.-- CHKENV requesting to examine if the environment of user A is suitable for operations of the selected software, to the host computer (step S13). In this case, user A selects Tetris. Accordingly, the software number 5 corresponding to Tetris is transmitted to the host computer.
The host computer which receives the software number selected by user A prepares a check script 5 for examining a consistency between the operating environment of the software corresponding to the received number and the environment of the terminal of user A, in order to check the environment.
Since this check is automatically made by the communication between an execution program of the check script 5 and the terminal software of the terminal, user A does not need to be aware that the environment check is performed (step S14). Only when an inquiry should be made to user A, the host computer makes an inquiry.
In this case, as the operating environment of Tetris selected by user A, the OS being used is WINDOWS, the machine type being used is a TOWNS, a PC98, etc., and the name of a directory (DIR) recommended is TET. In the meantime, the user A environment file 2 describes TOWNS as a machine type and WINDOWS as the OS. Comparing these descriptions proves that the machine type and the OS meet the requirements.
Since the check script 5 of Tetris includes a command "ST4 @WINDIR@VBRJP200.DLL" for examining if a file named "VBRJP200.DLL" is stored in the location WINDIR, for indicating the storage location of the OS on the user A side (MQ1), the host computer transmits this command together with a command RIS.sub.-- CHKENV*RESP. At this time, the host computer references the user A environment file 2, replaces the variable @WINDIR@ with D:WINDOWS, and transmits the replacing variable. Additionally, the file VBRJP200.DLL is one of the files required for operations of Tetris.
The terminal which receives this command examines if the directory WINDOWS in the drive D includes the file VBRJP200.DLL, and returns the result as an ANS to the host computer. Since there is no corresponding file in this case, ANS=OFF is returned.
The host computer, which determines that the file VBR200.DLL does not exist in the terminal, transmits an inquiry "Copy VBRJP200?" to the terminal according to the check script 5 (MQ2), and this inquiry is displayed on the screen of the display unit. The user enters an answer to the displayed inquiry, and the terminal returns the entered answer to the host computer. In this case, ANS="YES" is returned, and the host computer accepts a remote installation according to the check script 5 (RIS=OK), and sets a flag F2 instructing to copy the file VBRJP200.DLL to ON (MA2).
If the file VBRJP200.DLL exists in a designated directory in the terminal, ANS=ON is returned. Therefore, RIS=OK at that time (MA1).
As described above, automatically making an environment check prevents the distribution of software unsuitable for the environment of user A. For example, such a problem that a software package does not run due to a lack of a specific driver after it has been purchased via a communications line can be avoided.
The host computer completes the environment check when RIS=OK, and transmits the directory name SOUKODIR of the distribution destination together with the result of the check (JUDGE=OK) to the terminal. To the SOUKODIR, the recommended directory of Tetris TET is added as a subdirectory under the directory D:SOUKO of SOUKO stored in the user A environment file.
Simultaneously, information such as whether or not an installation is permitted (RIS), existence/non-existence of an icon registration of an installation program (installer) (ICON), and whether or not downloading is permitted (DLOAD), is transmitted to the terminal. By using the flags RIS, ICON, and DLOAD of these pieces of information, the host computer notifies the terminal which of the installation, the registration of the icon of the installer, and the downloading is possible.
The installation in this case means that software selected by user A is registered in, for example, WINDOWS, and allows the software to be used on the terminal. Accordingly, the installation in this case includes a step where an executable file of the software is registered as an icon in WINDOWS. In the meantime, the registration of the icon of the installer means that a program executing an installation is registered as an icon on the terminal.
In this case, conditions that the installation and the downloading are permitted (RIS=OK, and DLOAD=OK), and the registration of the icon of the installer is not permitted (ICON=NG), are presented. For software having a complicated installation program, it is presented that a registration of an icon of the installer is required for an installation. If a terminal running in WINDOWS requests application software supported by TOS (the operating system for TOWNS), downloading only is permitted.
Then, the terminal software of the terminal assigns priorities to the installation, the registration of the icon of the installer, and the downloading, in this order, sets one of them with a higher priority as a default, and displays it on the screen of the display unit. In this case, the installation whose priority is higher than that of the downloading is set as a default among the installation and the downloading permitted by the host computer, and displayed in an installation method selection window.
User A verifies the displayed installation method, and enters that the verification is completed (step S15). Alternatively, the user A can change the displayed settings at that time. If user A wants to register an icon of an installer, he or she can select and enter "icon registration of the installer" displayed in the installation method selection window.
Basically, if user A wants to perform a ready-made installation without performing a complicated process, he or she must select "system registration". If user A wants to make detailed installation settings, he or she must select "icon registration of the installer". To change a storage location later (to install the system on a terminal of another machine type), user A must select "downloading". Selecting "downloading" allows user A to obtain software for a machine different in type from the terminal, and to determine whether or not the software runs.
Then, the terminal automatically creates on a hardware disk a subdirectory for door-to-door distribution "D:SOUKOTET" as instructed by the host computer (step S16). If the subdirectory "D:SOUKOTET" already exists in the terminal, the terminal newly creates a subdirectory, for example, named "D:SOUKOTET001". If this subdirectory also exists, the terminal creates another subdirectory named "D:SOUKOTET002".
Program files of Tetris 6 are composed of a file named TET1.LZH (F1) and a file named VBRJP200.DLL (F2). The file TET1.LZH is generated by compressing four files such as TETRIS.EXE, TOWNS.DRV, PC98.DRV, and MAC.DRC. If TET1.LZH is expanded (decompressed) to the uncompressed state, it is divided into these four files. The file TET1.LZH is decompressed after being distributed from the host computer to the terminal.
After creating the subdirectory for door-to-door distribution, the terminal transmits a command RIS.sub.-- INSTALL requesting to start a remote installation, together with the number of the selected software, to the host computer (FIG. 1C, step S17). Upon receipt of the command and the name of the selected software, the host computer starts the remote installation of the software corresponding to the transmitted number. The remote installation is automatically performed by negotiation between the host computer and the terminal according to the installation script of Tetris created by the host computer (step S18) The installation script 7 includes an instruction for downloading the file TET1.LZH into a storage location of user A, that is, @SOUKODIR@. The host computer replaces @SOUKODIR@ with SOUKODIR=D:SOUKOTET, and downloads TET1. LZH into the subdirectory D:SOUKOTET of the hard disk.
When notified from the terminal that the downloading is completed, the host computer replaces @WINDIR@ with D:WINDOWS, and downloads the file VBRJP200.DLL into the directory D:WINDOWS on the hard disk.
When notified from the terminal that the downloading is completed (OK), the host computer then transmits an instruction LHA X D:SOUKOTETTET1.LZH to decompress the downloaded file TET1.LZH in the storage location @SOUKODIR@ (D:SOUKOTET). Upon receipt of this instruction, the terminal decompresses the file TET1.LZH to the four files such as TETRIS.EXE, TOWNS.DRV, PC98.DRV, and MAC.DRC. These four files are stored in the same subdirectory D:SOUKOTET as that including the file TET1.LZH.
When notified from the terminal that the decompression is completed (OK), the host computer moves a file @MACHINE.sub.-- TYPE@.DRV stored in the location @SOUKODIR@ (D:SOUKOTET) to the storage location @WINDIR@ (DWINDOWS), and transmits an instruction MOVE D:SOUKOTETTOWNS.DRV D:z,1 WINDOWSFONT.DRV rename the file to FONT.DRV.
At this time, the host computer references the user A environment file 2, replaces @MACHINE.sub.-- TYPE@ with TOWNS, and transmits the instruction. Upon receipt of the instruction, the terminal moves the file TOWNS.DRV included in the subdirectory D:SOUKOTET to the directory D:WINDOWS (file move), and renames the file FONT.DRV (renaming).
When notified from the terminal that the file move and the renaming are completed (OK), the host computer then transmits an instruction ICON TETRIS.EXE for registering an icon of a file TETRIS.EXE. Upon receipt of this instruction, the terminal registers the file TETRIS.EXE included in the subdirectory D:SOUKOTET in the terminal as an icon.
After that, an icon for invoking the file TETRIS.EXE is displayed in a directory window. Clicking the mouse button with the icon pointed to starts the operation of Tetris.
When notified from the terminal that the registration of the icon is completed (OK), the host computer sends back RETURN in order to notify the terminal of the completion of the remote installation, and the sequence of installation operations is completed. After having been notified that the remote installation is completed, the terminal selects the next software and performs its remote installation according to an instruction of user A, or terminates the process (step S19).
The conventional technology of managing software to be distributed using the remote installation system when the software is sold to users can be "IDENTIFIER MANAGING DEVICE AND METHOD IN SOFTWARE DISTRIBUTION SYSTEM, U.S. patent application Ser. No. 08/571,104, and Japanese Patent Laid-open H8-190529"
In this system, the host computer issues a terminal identifier (machine ID: MID) to each user terminal, and issues a user identifier (user ID; UID) other than the machine ID to a terminal user. The host computer sets a terminal password (machine password: MPSW) for each machine ID and a user password for each user ID.
The host computer manages the terminals and the users which receive distributed software programs using the machine ID, the machine password, the user ID, and the user password.
If the software program sold to the user becomes unserviceable for some reason, the host computer restores the software program by referring to the sales record. The host computer also provides an update service for the sold software programs. Furthermore, by dynamically changing the terminal passwords provided for the terminals and checking the terminal passwords, the host computer observes whether or not the installed software program is duplicated into other terminals.
When the terminal is transferred from a user to another user, the software program installed in the terminal may be transferred with the rights to receive an update service and a recovery service for the software program from the host computer. This transfer system protects the software from being illegal copied and is useful for both user and vendor because these rights can be easily transferred through the network.
By referring to FIGS. 2A through 2D, the flow of the processes according to the software distribution system of this embodiment will be described.
FIG. 2A is a flow-chart showing the registration process for user identifier UID. When the process is started, the user connects his terminal with the host computer in the distribution center (step S21), then, inputs his name, the number of his cash card, and personal information of, for example, his address (step S22). Receiving this input information, the host computer issues a temporary user identifier and a temporary user password to temporarily register the user (step S23). After that, the user signs off the connection to the host computer, and waits for the authentication of the cash card (step S24).
After the cash card is authenticated, the distribution center mails an official user identifier UID and an official user password PSW to the user (step S25). Then, the user connects the terminal with the host computer again (step S26), and enters the received official user identifier UID and the received official user password PSW to the host computer from the terminal (step S27).
Receiving these data, the host computer recognizes that the user has received the official user identifier UID and the official user password PSW, registers the user officially, and finishes the process. The user can input another password together with the mailed user password PSW and register these passwords.
FIG. 2B is a flow-chart showing the registration process for the terminal identifier MID. When the process is started, the user connects his terminal to the host computer in the distribution center (step S31) and inputs the registered user identifier UID and the registered user password PSW (step S32). Then, the terminal sends the machine information on the type of the terminal, the OS used in the terminal, and the like, to the host computer automatically (step S33). The host computer issues and attaches the terminal identifier MID and the terminal password MPSW to the received machine information, stores them in the specified format, and sends the terminal identifier MID and the terminal password MPSW back to the terminal (step S34). The issued terminal identifier MID and the issued terminal password MPSW are stored in the terminal.
FIG. 2C is a flow-chart showing the software selling process, in which the software program is sold to a user registered in the distribution center through the network.
When the process is started according to, for example, a request from the user, the terminal of the user is connected to the network (step S41). Then, the host computer checks the user identifier ID and the user password (step S42). If these data is not correct (NG), the process is finished.
If the user ID and the user password are correct (OK), the host computer automatically reads and checks the terminal ID and the terminal password stored in the terminal (step S43). If the terminal ID and the terminal password are not correct, it can be considered that data have been illegally copied, and a process against the illegal action is performed (step S44).
If the terminal ID and the terminal password are correct (OK), the host computer displays the list of software programs to be sold on the screen of the terminal, and the user can choose a software program from the list (step S45). The user selects the program from the list or inputs a request for the recovery of the software program if it is needed.
Next, the host computer determines whether the request from the user is a purchase request or a recovery request (step S46). If the user requests a recovery service, the host computer checks whether or not the user has purchased the corresponding software program before by referring to the purchase information of the user (step S47). If the user did not purchase the software program (step S47, NO), control is returned to step S45 because the user does not have the right to receive the recovery service.
If the user requests a recovery service for the software program the user has purchased before (step S47, YES), the host computer delivers the requested software program to the terminal to install it again (step S49). Then, the host computer demands the payment from the user according to a usage contract (step S50) and finishes the process. If a recovery service is described as a charge-free service according to the contract, the service is provided free of charge.
If the host computer receives the purchase request for the software program from the user in step S46, the host computer decides to sell the chosen software program (step S48) and delivers the software program to the terminal to install it (step S49). Then, the host computer demands the payment from the user (step S50) and finishes the process.
In step S50, the payment is imposed on the user who has been assigned the input user identifier, and the management of the user ID is entrusted to the user. Each user designates the user password to manage the user ID.
If the sales contract for the software program indicates that the software program is sold to the terminal in which the software program is installed and is not sold to the user, the payment is imposed on the terminal in step S50. In this case, the host computer checks whether or not the corresponding software program is sold to the terminal at step S47, and provides the restoration service only if the software program has been sold to the terminal.
The host computer adds a terminal password to the terminal with the terminal identifier and automatically updates the terminal password to manage it every time the terminal is connected to the host computer. If the sold software program is duplicated illegally, access is gained using the terminal password used before the update. Therefore, the host computer can recognize the illegal duplication. The host computer can trace back the terminal identifiers and the terminal passwords.
FIG. 2D is a flow-chart showing the check process and rewriting process for the terminal password in step S43, and the process against an illegal action in step S44.
When the process is started, the host computer compares the terminal password of the connected terminal with the terminal password provided when the terminal was connected the last time (step S51).
If the two terminal passwords match each other, the host computer creates a new terminal password to write it into the terminal and also stores it in the host computer (step S52). The new terminal password is assigned using a random number, that is, an unpredictable number. The old terminal password is also stored in the host computer to be referred to later (step S53), then the process finishes.
When the two terminal passwords do not match each other in step S51, the host computer decides that an unauthorized duplication has been made, and assigns a new terminal identifier to the connected terminal to manage the terminal (step S54). Furthermore, the host computer continuously compares the terminal password obtained in the current connection with old terminal passwords stored in the host computer to find the date of the last access which was done using this terminal password (step S55), thereby specifying the time at which the unauthorized duplication was made. The date can be obtained by referring to date information stored in the host computer. After step S55, the process is finished.
The prior art technology of entering in the remote installation system the software generated by a user can be "SOFTWARE REGISTERING/MANAGING SYSTEM AND METHOD THEREOF, U.S. patent application Ser. No. 08/724,675, Japanese Patent Application H7-258506."
FIG. 3A is a block diagram showing the structure of locations formed in this system. In the system shown in FIG. 3A, user groups referred to as clubs form virtual places in the host computer for exchanging software information. Users associated with each club are referred to as members, too. In FIG. 3A, clubs 12, 13, and 14 are included in the same hierarchical level. Each of the clubs 12, 13, and 14 has the functions of a conference room and a remote installation system (RIS).
A high order club 11 is disposed in a higher hierarchical level than the clubs 12, 13, and 14. In this example, the number of hierarchical levels is two. However, it should be noted that the number of hierarchical levels is not limited to two. Generally, a software program delivered to a user is uploaded and registered to any club. For example, when a software program 15 is uploaded to the club 12, the software program 15 is first registered to the club 12. Thus, the club 12 becomes the original club. To transfer the software program registered in the original club to another club, there are two methods, namely a linking method and a moving method.
When the linking method is used, the software program can be seen from other clubs than the original club. On the other hand, when the moving method is used, the function of the original club is moved to another club. A member who wants the software program 15 can download it from one of the original club 12 and the linked clubs 11 and 13.
Normally, the member who created the software program 15 has the right to select an original club. However, after the member has uploaded the software program 15 and has given permission to publish it, the right to link the software program or move the authority of the original club to another club is transferred to the supervisor (manager) of the original club. In the practical management of the system, this right should be arranged between a member who uploads a software program and the supervisor of the original club. In the computer system, the duties and rights of the creator of a software program and individual supervisors may be set forth in a contract as follows.
(1) Rights and duties of a creator of a software program PA1 (2) Rights and duties of the supervisor of the original club PA1 (3) Rights and duties of the supervisor of a linked club PA1 (4) Rights of the supervisor of a high order club
Right to upload the software program PA2 Right of the creator to deliver a software program as a test delivery without a fee (namely, the fee for an RIS for testing is free) PA2 Right to permit publishing of a software program he has created PA2 Duties of the creator to support a software program that he has uploaded (for example, he should answer questions from the users of the software program, and correct any errors in the software program) PA2 Right to test software programs uploaded to the club without a fee (the fee for using software programs for testing is free) PA2 Right to publish software programs uploaded to the original club PA2 Right to permit a linked club to link a software program to the linked club PA2 Duty to support software programs in the original club PA2 Duty to permit high order clubs to link software programs to other clubs, unless a justifiable reason exists PA2 Right to publish software programs that are permitted to be linked PA2 Duty to support software programs in the club PA2 Right to publish software programs that are permitted to be linked
Since high order clubs can normally link software programs of low order clubs to themselves, members of the highest order club can see all software programs in the system. In addition, under the condition that the supervisor of the linked club supports the usage of a software program and so forth, the software program is linked to the linked club. Thus, in a club where the members can view a software program, the members can receive the support for the software program.
Next, with reference to FIGS. 3B through 3D, the operations of a creator of a software program and supervisors will be described.
FIG. 3B is a flowchart showing the operation of the program creator. In FIG. 3B, when the operation is started, a creator creates a software program and prepares a file group to be uploaded (at step S61). Thereafter, the creator selects a club to which he wants to upload the created program. With the UPLOAD command, the program creator uploads the software program (at step S62) and receives the result of an automatic check (in step S63).
At this point, the host computer automatically performs a malfunction check, a virus check, a copyright check, a trademark check, and so forth. When an error is detected as a result of these check processes (at step S64), the creator corrects errors and uploads only the corrected portions (at step S65). Then, the creator repeats the operation from step S63.
After the automatic checks have been successfully completed, the creator performs a test delivery using the RIS command (in step S66). In the test delivery, it is determined whether or not the uploaded software program can be remotely installed without a problem (in step S67). When an error takes place in the test delivery, the creator corrects the error portion and uploads the corrected portion again (in step S68). Then, the processes in and after step S66 are repeated. When the test delivery is successfully performed, the creator permits the software program to be published using the PUSH command (in step S69). Thus, the creator finishes the operation.
FIG. 3C is a flow chart showing the operation of a supervisor of an original club. When the operation is started, the supervisor performs a test delivery of a software program permitted to be published by the creator thereof (in step S71) and checks whether or not the software program is normal (in step S72). When the test delivery is successfully completed, the supervisor publishes the software program to the members of the original club using the command PUBLISH (in step S73). When the software program has a problem, the supervisor notifies the creator of the problem (in step S74). Thus, the supervisor finishes the operation.
FIG. 3D is a flowchart showing the operation of the supervisor of a linked club. When the supervisor of the linked club finds a desired software program after the operation is started, he or she sends a linking request to the original club (at step S81) and receives the reply of the request (at step S82). When the original club does not permit the linking request, the supervisor finishes the operation. When the original club permits the linking request using the command PERMISSION, the supervisor of the requested club links the software program with the command LINK (step S83). At this point, the supervisor changes keywords so that the members of the club can easily retrieve the software program.
Then, the supervisor of the linked club performs a test delivery of the software program (at step S84) and checks whether or not the software program is normal (in step S85). When the software program is normal, the supervisor of the linked club publishes the software program to the members of the club using the command PUBLISH (at step S86). When the software program has a problem, the supervisor of the linked club notifies the original club of the problem (in step S87). Thus, the supervisor finishes the operation.
There are various types of software distributed in the communications using personal computers. For example, freeware is normally distributed free of charge. Shareware is once distributed free of charge with available functions limited for a predetermined period, and then the limitations are released when a predetermined fee is paid by the user. If a software is sold as a product, it is delivered upon receipt of the fee.
When the delivery center provides software for the users based on the remote installation function, a system of receiving the fees without fail for various services and products is required. An example of settling the payment can be "SOFTWARE CHARGE DETERMINATION SYSTEM AND METHOD, U.S. patent application Ser. No. 08/693,467, Japanese Patent Application H7-258507."
FIG. 4A shows an example of the uploading process of a file group used in this system. The creator of shareware uploads a CFG file 21 (AAA.CFG), an explanatory file 22 (AAA.TXT), an installation related file 23 (an icon file ICON.DEF in this case), and a program file 24 (AAA.LZH) as a program registration file from his or her own terminal.
A host computer registers the uploaded information to a contents database 28. In this case, software code, name, type (TYPE), name of program file, name of explanatory file, name of icon file, etc. of the uploaded software "AAA scheduler" are registered as management information. SHARE in [type] indicates that the type of software is shareware. The contents database 28 is provided in, for example, the host computer or in an external disk unit.
Then, the creator uploads a definition file 25 (AAAS.CFG), a CHK file 26 (AAAS.CHK), and a rewrite file 27 (INI.DEF) as remittance procedure files. By uploading such files, the software code, name, type, name of CHK file, name of file for post-process, etc. of the remittance procedure file AAAS are registered in the contents database 28.
In this case, the name of the rewrite file 27 INI.DEF is registered as the file for a post-process. Additionally, a SOKIN#RIS in TYPE indicates that the type of software is a remittance procedure file for shareware which corresponds to the information in [instype] of the definition file 25 (AAAS.CFG).
The explanation about the remittance procedure for shareware using an uploaded group of files is provided next by referring to FIGS. 4B through 4E. According to the remittance procedure for shareware, a remittance flag is set for a protocol in addition to the procedure for a remote installation. By setting the remittance flag in order to request a software search from a terminal, the remittance procedure for shareware can be selected. Additionally, a menu for setting the remittance flag to ON/OFF is displayed on the screen of the terminal. In this example, it is assumed that the shareware "AAA scheduler" has already been installed in a user system with its functions restricted before the remittance procedure. If a user attempts to purchase this shareware, the following commands/responses are exchanged between a host computer and a terminal.
The terminal transmits a user environment to the host computer (step S91 shown in FIG. 4B). The host computer returns a response upon receipt of the user environment (step S92). When the user requests a keyword list to retrieve software (step S93), the host computer returns the keyword list (step S94).
As shown in FIG. 4C, a menu 29 of option procedures is displayed on the screen of the terminal. The user specifies "remittance" from among the displayed options, and selects a keyword from the keyword list. As a result, the remittance flag SOKIN is set to ON, and an instruction to start retrieving the shareware is transmitted to the host computer (step S95 shown in FIG. 4C).
The host computer searches for the contents database 28 using a specified keyword, and returns the name of software whose type starts with SOKIN, and the software code of its remittance procedure file (remittance software) (step S96). In this case, names such as AAA scheduler, BBB scheduler, etc. and software codes 4000, 4001, etc. are returned.
The terminal lists the remittance software only, and the user specifies a particular piece of remittance software in the listed software (step S97). In this case, the software code 4,000 is specified. The host computer negotiates with the terminal side under the condition of the remittance software having the software code 4000 (step S98). At this time, the host computer instructs the terminal to examine the location of the initialization file AAA.INI stored in the user system using a command ST4. Then, the terminal examines the location of the file AAA.INI, and notifies the host computer that the location is E:AAA (step S99). The command ST4 is assumed to be supported on the terminal side.
Then, the host computer makes the terminal display a dialog box 30 on its screen, and asks the user if the location of the file AAA.INI is correct (step S100 in FIG. 4D). If the directory displayed in the dialog box 30 is correct, the user returns that directory as is (step S101). The host computer then determines that a directory path of the file to be rewritten in the user system is E:AAAAAA.INI.
If the displayed directory is incorrect, the user enters the correct name of the directory. Assuming that the user makes an entry such as G:GGG, the terminal returns a directory path G:GGGAAA.INI to the host computer. Since the storage location of the file AAA.INI is determined, the host computer notifies the terminal that the remittance of the shareware charge can be made (step S102).
Then, the user requests the release of the functional restriction on the shareware (step S103 shown in FIG. 4E). In response to this request, the host computer references [instype] in the definition file 25 shown, withdraws the charge from the account of the user, and transmits a rewrite file INI.DEF describing the rewriting process of the file AAA.INI. Furthermore, the host computer references [last] in the definition file, and transmits a post-process command CHGINI in order to instruct the terminal to rewrite the file according to the procedure described in the file INI.DEF.
Then, the terminal references the downloaded file INI.DEF, and rewrites the file AAA.INI. Thus, the functional restriction of the shareware "AAA scheduler" is released so that the shareware can run on the user system properly. After that, the host computer deletes the file INI.DEF from the terminal, and terminates the process.
Since the definition file 25 indicates in [instype] that the functional restriction is released immediately when the charge is remitted, the functional restriction of the shareware is released simultaneously with the withdrawal of the charge. Alternatively, like a general personal computer communication center, the host computer may only perform a charge withdrawal and an electronic mail issuance to a person who has registered for shareware.
FIGS. 4F, 4G, and 4H are schematic diagrams showing the procedure for withdrawing a charge for the shareware "BBB scheduler". This process assumes that the shareware "BBB scheduler" is installed on a user terminal and restricted in function. When a user attempts to purchase this shareware, commands/responses are exchanged between the host computer and the terminal as follows.
The terminal first transmits a user environment to the host computer (step S111 in FIG. 4F). The host computer returns a response upon receipt of the user environment (step S112). When the user requests a keyword list for software search (step S113), the host computer returns the keyword list (step S114).
As shown in FIG. 4G, a menu 29 of option procedures is displayed on the screen of the terminal. The user selects "remittance" from the menu, and also selects a keyword from the keyword list. As a result, a remittance flag SOKIN is set so that an instruction to start the shareware search can be transmitted to the host computer (step S115 shown in FIG. 4G).
The host computer searches for a contents database 28 using the selected keyword, and returns the name of shareware whose type begins with SOKIN and the software code of the remittance software (step S116). The terminal lists remittance software only, and the user selects the remittance software having the software code 4001 from the listed software (step S117).
Then, the host computer makes the terminal display a message 31 on its screen, and asks the user if the charge is acceptable (step S118 shown in FIG. 4H). The host computer references [instype] in the definition file BBBS.CFG, changes the value of the flag SOKIN into 0.times.08 indicating only an e-mail issuance, and returns the value to the terminal.
The user selects OK if the charge is acceptable, or selects NG if the user does not want to purchase the shareware. In this case, OK is selected, and a request to send e-mail to the person who makes the registration is transmitted from the terminal to the host computer (step S119).
Upon receipt of the request, the host computer withdraws the charge from the account, etc. of the user, and transmits the e-mail notifying the person who registers the BBB scheduler that the charge has been withdrawn. The destination address of the e-mail is the remittee FJOKI set in [type] of the definition file.
When the person who makes the registration receives that e-mail from the host computer, he or she notifies the person who purchased the shareware of a method for releasing a functional restriction through e-mail, etc. As a result, the person who purchased the shareware can use all of the functions of the BBB scheduler.
However, the above described conventional remote installation system has the following problem.
Since marketed software normally contains undisclosed information, it should be distributed through a secured line. Therefore, if the software is installed on the Internet through which security is not preliminarily guaranteed, then a countermeasure should be taken against hacking.
A method of linking a world wide web (WWW) browser, which is a software tool for retrieving information through the Internet, and a remote installation system should be prepared in various configurations corresponding to respective services provided for users.
The machine ID of a terminal in the conventional remote installation system is designed/managed on the premise that there is only one host computer. Therefore, if services are provided using a plurality of host computers, each of the host computers may assign the same machine ID to different terminals. In this case, there arises the problem that the host computers cannot correctly identify terminals.
Furthermore, since identification information may be illegally accessed through the Internet, it is very difficult to correctly identify a correspondent in communications. As a result, a third party can pretend to be a host computer of an RIS using illegally acquired identification information. Therefore, the users should be able to detect illegal operations.